home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000029_owner-urn-ietf _Thu Jan 30 16:12:22 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA14430 for urn-ietf-out; Thu, 30 Jan 1997 16:12:22 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA14425 for <urn-ietf@services.bunyip.com>; Thu, 30 Jan 1997 16:12:20 -0500
  3. Received: from ritig1.rit.reuters.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA17185  (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 16:12:14 -0500
  5. Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM)
  6.     id AA01134; Thu, 30 Jan 1997 15:05:27 -0500
  7. Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.1-5 #7805)
  8.  id <01IETW5M12000000BC@RITIG4.RIT.REUTERS.COM> for urn-ietf@bunyip.com; Thu,
  9.  30 Jan 1997 16:10:55 EST
  10. Received: with PMDF-MR; Thu, 30 Jan 1997 21:11:09 +0000 (GMT)
  11. Mr-Received: by mta REC.MUAS; Relayed; Thu, 30 Jan 1997 21:11:09 +0000
  12. Mr-Received: by mta RE6; Relayed; Thu, 30 Jan 1997 21:11:09 +0000
  13. Mr-Received: by mta RITIG4; Relayed; Thu, 30 Jan 1997 21:10:44 +0000
  14. Disclose-Recipients: prohibited
  15. Date: Thu, 30 Jan 1997 21:11:09 +0000 (GMT)
  16. From: Ian Higgs +44 171 542 8595 <IAN.HIGGS@reuters.com>
  17. Subject: [URN] Fragment references.
  18. To: URN Mailing list <urn-ietf@bunyip.com>
  19. Message-Id: <4109112130011997/A32374/RE6/11B1F54B0800*@MHS>
  20. Autoforwarded: false
  21. Mime-Version: 1.0
  22. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  23. Importance: normal
  24. Priority: urgent
  25. Sensitivity: Company-Confidential
  26. Ua-Content-Id: 11B1F54B0800
  27. X400-Mts-Identifier: [;4109112130011997/A32374/RE6]
  28. Hop-Count: 2
  29. Sender: owner-urn-ietf@services.bunyip.com
  30. Precedence: bulk
  31. Reply-To: Ian Higgs +44 171 542 8595 <IAN.HIGGS@reuters.com>
  32. Errors-To: owner-urn-ietf@bunyip.com
  33.  
  34. Somebody asked:
  35. > How is a location within a resource really different from a relative
  36. > URN?
  37.  
  38. I would say that a relative reference always implies a new request,
  39. but an internal fragment reference does not. An internal fragment 
  40. reference just implies a scroll in the display.
  41.  
  42.  
  43. However, as I understand the existing specifications, there could be 
  44. two possible understandings of fragment references.
  45.  
  46. ++++
  47.  
  48. Imagine a resource includes a link <A HREF="#somewhere">...
  49.  
  50. ++ Case 1
  51.  
  52. The browser "knows" that # means relative, scans the current resource 
  53. for the matching <A NAME="somewhere"> and adjust the display to that 
  54. location.
  55.  
  56. ++ Case 2
  57.  
  58. The browser takes the reference used to get the resource in the first
  59. place (URL or URN), strips off any existing "#xxx" and adds the new
  60. "#somewhere".
  61.  
  62. The resulting reference is passed to a lower part of the software
  63. which is asked to fetch the resource.
  64.  
  65. The "fetcher" strips the "#somewhere" off again, looks in the cache 
  66. and finds a resource matching the reference or sends out a new
  67. request for it.
  68.  
  69. The browser gets the returned resource and THEN performs the scan
  70. as in case 1.
  71.  
  72. ++++
  73.  
  74. In the first case, the browser does not repeat the request.
  75. In the second case it may.
  76.  
  77. Current practice seems to be the first case, so that:
  78.  
  79. - the "browser" does not include the "#somewhere" in the request.
  80. - the "#somewhere" is not used or meaningful to the resolver or server.
  81. - the COMPLETE resource is always returned.
  82.  
  83. For a URL this raises interesting questions. If the URL refers to 
  84. a script rather than a fixed resource, then the first case is 
  85. displaying a stale result and the second case implies a refresh 
  86. which may return a different result if the resource is not cached.
  87.  
  88. If we say that the value of a URN is the persistence of the resource,
  89. regardless of the physical location, then I assume that the two 
  90. cases are equivalent, since the resource should not have changed.
  91.  
  92. If we say that the value of a URN is the implied indirection that 
  93. insulates us from the physical location of the resource, then it is 
  94. possible that the resource can change between requests or that the 
  95. requests are resolved to different copies/versions of the resource.
  96.  
  97. Does this possibility matter to us?
  98.  
  99. /Ian Higgs
  100.